C Secure Coding Rules: Past, Present, and Future

• Developers lack appropriate secure coding standards that they can use to substitute analyzable correct code in place of insecure antipatterns (that is, noncompliant code).
• Analyzers do not have a consistent set of requirements for which insecure coding errors must be diagnosed.
• Analyzers must be validated through conformance testing so that they can be used as trusted programs.

For nearly 10 years, the Secure Coding Initiative at CERT has been working toward solving these problems by creating secure coding guidance for developers. CERT is also working with ISO/IEC to establish a baseline set of requirements for analyzers and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. CERT is also developing a set of tests to evaluate conformance to these requirements.

CERT's Secure Coding Standards are being widely adopted by industry. Cisco Systems, Inc. announced its adoption of the CERT C Secure Coding Standard as a baseline programming standard in its product development in October 2011 at Cisco's annual SecCon conference. Recently, Oracle has integrated all of CERT's secure coding standard into their existing Secure Coding Standards. Note that this adoption is the most recent step of a long collaboration: CERT and Oracle having previously worked together in authoring The CERT Oracle Secure Coding Standard for Java.

Past

I became involved with the C Standards Committee (more formally, ISO/IEC JTC1/SC22/WG14) during the writing of the first edition of Secure Coding in C and C++. At the time, WG14 was working on a document called "C Library Security TR 24731," which was meant to standardize the "_s" functions developed by Microsoft. I exchanged some email with Randy Meyers, who was chair of J11 (which became PL22.11), concerning the odd behavior of the gets_s() function, which failed to consume the end-of-line character. I ended up attending the WG14 meeting in Lillehammer, Norway, in the spring of 2005, and CERT has remained involved with the C Standards Committee ever since.

NOTE
Task Group PL22.11, Programming Language C, is responsible for the technical development of the standard for C programming language. This technical committee is the U.S. Technical Advisory Group to ISO/IEC JTC 1 SC22/WG14.

At the Spring 2006 WG14 Berlin meeting, Dr. Thomas Plum approached me with the idea of CERT creating a secure coding standard. At the time, the closest thing was MISRA C: 2004 Guidelines for the Use of the C Language in Critical Systems. However, these guidelines were for safety-critical systems, which have substantially different requirements than most systems that need to be secured, and those 2004 guidelines also precluded all the language features that had been introduced by ISO/IEC 9899:1999.

Immediately I saw the wisdom of Tom's proposal. The C Standard is an authoritative document, but its audience is primarily compiler implementers, and, as noted by many, its language is obscure and often impenetrable. A secure coding standard would be primarily targeted toward C language programmers and would provide actionable guidance on how to code securely in the language.

The CERT C Secure Coding Standard was developed on the CERT Secure Coding wiki following a community-based development process. Experts from the community, including members of the WG14 C Standards Committee, were invited to contribute and were provided with edit privileges on the wiki. Members of the community can register for a free account on the wiki and comment on the coding standards and the individual rules. Reviewers who provided high-quality comments were frequently extended edit privileges so that they could directly contribute to the development and evolution of the coding standard. Today, the CERT Secure Coding wiki has 1,374 registered contributors.

This wiki-based community development process has many advantages. Most important, it engages a broad group of experts to form a consensus opinion on the content of the rules. The main disadvantage of developing a secure coding standard on a wiki is that the content is constantly evolving. This is great if you want the latest information and you are willing to entertain the possibility that a recent change has not yet been fully vetted. However, many software development organizations require a static set of rules and recommendations that they can adopt as requirements for their software development process. Toward this end, we produced a stable snapshot of the CERT C Secure Coding Standard after two and a half years of community development, and published it as The CERT C Secure Coding Standard (Addison-Wesley, 2008). This book serves as version 1.0 of the CERT C Secure Coding Standard. With the production of the manuscript for this book in June 2008, version 1.0 (the book) and the wiki versions of the Secure Coding Standard began to diverge.

The CERT C Secure Coding guidelines were first reviewed by WG14 at the London meeting in April 2007 and again at the Kona, Hawaii meeting in August 2007.

The topic of whether PL22.11 should submit the CERT Secure Coding Standard to WG14 as a candidate for publication as a type 2 or type 3 technical report was discussed at the J11/U.S. TAG Meeting, April 15, 2008, as reported in the minutes. A straw poll was taken on the question, "Who has time to work on this project?" for which the vote was 4 to 12. The decision was made to take no further action. Some of the feedback we received afterwards was that although the CERT C Secure Coding Standard was a very strong set of guidelines that had been developed with input from many of the technical experts at WG14 and had been reviewed by WG14 on several occasions, WG14 was not normally in the business of "blessing" guidance to developers. However, WG14 was certainly in the business of defining normative requirements for tools, such as compilers.

Armed with this knowledge, we proposed that WG14 establish a study group to study the problem of producing analyzable secure coding guidelines for the C language. The study group first met on October 27, 2009. Thomas Plum served as the inaugural chair, and I was elected as the project editor. CERT contributed a set of automatically enforceable C Secure Coding rules to ISO/IEC for use in the standardization process.

David Keaton, the current PL22.11 chair, eventually replaced Tom as chair of the study group. Participants in the study group included analyzer vendors such as Coverity, Fortify, GammaTech, Gimpel, Klocwork, and LDRA; security experts; language experts; and consumers. A new work item to develop and publish ISO/IEC TS 17961 C Secure Coding Rules was approved for WG14 in March 2012, and the study group concluded. Roberto Bagnara from the Applied Formal Methods Laboratory at the University of Parma and BUGSENG later joined the WG14 editorial committee.

Present

The purpose of ISO/IEC TS 17961 is to establish a baseline set of requirements for analyzers, including static analysis tools and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The criterion for selecting these rules is that analyzers that implement these rules must be able to effectively discover secure coding errors without generating excessive false positives.

To date, the application of static analysis to security has been performed in an ad hoc manner by different vendors, resulting in nonuniform coverage of significant security issues. ISO/IEC TS 17961 enumerates secure coding rules and requires analysis engines to diagnose violations of these rules as a matter of conformance to the specification. These rules may be extended in an implementation-dependent manner, which provides a minimum coverage guarantee to customers of any and all conforming static analysis implementations.

ISO/IEC TS 17961 specifies rules for secure coding in the C programming language and code examples. It does not specify the mechanism by which these rules are enforced or any particular coding style to be enforced. Each rule in this document is accompanied by code examples. Noncompliant code examples demonstrate language constructs that have weaknesses with potentially exploitable security implications; such examples are expected to elicit a diagnostic from a conforming analyzer for the affected language construct. Compliant examples are expected not to elicit a diagnostic.

The following table shows how ISO/IEC TS 17961 relates to other standards and guidelines. Of the publications listed, ISO/IEC TS 17961 is the only one for which the immediate audience is analyzers and not developers.

A conforming analyzer must be capable of producing a diagnostic for each distinct rule in the technical specification upon detecting a violation of that rule in isolation. If the same program text violates multiple rules simultaneously, a conforming analyzer may aggregate diagnostics but must produce at least one diagnostic. The diagnostic message might be of the form

 Accessing freed  memory in function abc, file xyz.c, line nnn.

ISO/IEC TS 17961 does not require an analyzer to produce a diagnostic message for any violation of any syntax rule or constraint specified by the C Standard. Conformance is defined only with respect to source code that is visible to the analyzer. Binary-only libraries, and calls to them, are outside the scope of these rules.

An interesting aspect of the technical specification is the portability assumptions, known within the group as the "San Francisco rule" because the assumptions evolved at a meeting hosted by Coverity at its headquarters. The San Francisco rule states that a conforming analyzer must be able to diagnose violations of guidelines for at least one C implementation, but does not need to diagnose a rule violation if the result is documented for the target implementation and does not cause a security flaw. Variations in quality of implementation permit an analyzer to produce diagnostics concerning portability issues. For example, the following program fragment:

  long i;  printf("i = %d", i); 

can produce a diagnostic, such as the mismatch between %d and long int.

This mismatch might not be a problem for all target implementations, but it is a portability problem because not all implementations have the same representation for int and long.

CERT has also developed the Secure Coding Validation Suite, a set of tests to validate the rules defined in TS 17961. These tests are based on the examples in this technical specification and are distributed with a BSD-style license.

Future

Committee draft 17961 (SC 22 N 4780) was balloted in early 2013 and was returned with 13 yes votes and 1 no vote (Netherlands). Ballot comments were reviewed at the WG14 meeting in Delft, Netherlands, in April 2013. A preliminary draft of ISO/IEC PDTS 17961 is being prepared for a second ballot.

Because both the C programming language and our knowledge of how to use it securely is still evolving, CERT will continue to manage the community development of the CERT C Secure Coding Standard on the secure coding wiki. In particular, the CERT C Secure Coding Standard is being updated for consistency with ISO/IEC TS 17961 and for the C11 major revision to the C Standard. These changes may then be incorporated into future, officially released versions of this standard. This new version will be submitted to Addison-Wesley for publication.